HTTP-based Proxy Services
The device can be configured as an HTTP Proxy (or a non-HTTP Proxy) to intermediate between clients (e.g., HTTP requests) and servers (hosts). The client sends an HTTP GET request specifying the destination (URL), and the device (acting as an HTTP Proxy), forwards it to the host, and vice versa.
This feature integrates the NGINX platform, which is an open source proxy server. When you enable the HTTP Proxy application, the NGINX daemon is launched. When you then configure the various HTTP Proxy tables, the configuration is reflected in the NGINX configuration file (nginx.conf). Each parameter has its own NGINX Directive notation syntax, which is shown in the nginx.conf file. For example, if you have configured an Upstream Host (discussed later in this section), it is displayed in the NGINX file as "server host:port". You can also configure and apply additional NGINX Directives that do not have any corresponding parameters in the device's Web interface. For more information, see Configuring HTTP Directive Sets.
The device supports the following proxy services:
|
■
|
HTTP Reverse Proxy for managing equipment behind NAT: You can configure the device to function as a Reverse HTTP Proxy server. You can use this for many HTTP-based applications. For example, you can use it to intermediate between REST API clients and a REST server. |
Another example is to use the HTTP Proxy to intermediate between IP Phones and remote servers for file download. The figure below illustrates this example where IP Phones (clients) retrieve their configuration and firmware files from remote file servers (Upstream Hosts) and where the device (HTTP Proxy) intermediates between the two. The HTTP hosts are located in the cloud and the clients are located behind NAT. The HTTP Proxy listens for incoming HTTP requests (Listening Interface and HTTP/S Listening Port) from the clients and then forwards the requests to the relevant HTTP host, based on the URL (HTTP Location) in the incoming HTTP GET request. If the URL matches the pattern "/firmware/", the HTTP Proxy sends the request to the firmware file server; if the URL matches the pattern "/ipp/*.cfg", the requests are sent to the configuration file server. In addition, customized NGINX directives have been configured for each HTTP Location to define the maximum time to wait for an HTTP connection.
A summary of the required configuration for this example is listed below:
|
b.
|
Configure two Upstream Groups, where each is configured with an Upstream Host that defines the IP address of the HTTP host (i.e., firmware and configuration file servers). See Configuring Upstream Groups.
|
|
e.
|
Configure a local, IP network interface for the outbound leg interfacing with the HTTP hosts (or use the default).
|
|
f.
|
Configure the HTTP Proxy server, by assigning it the listening IP network interface and configuring a listening HTTP/S port (see Configuring HTTP Proxy Servers).
|
|
g.
|
Configure two HTTP Locations for the HTTP Proxy server, where each is configured with a URL pattern to match the incoming HTTP requests for determining the destination host (Upstream Group-Upstream Host). In addition, assign it the relevant HTTP Directive Set.
See Configuring HTTP Locations. |
|
■
|
Non-HTTP Proxy (referred to as TCP/UDP Proxy Server): The device can serve as a proxy for other applications that are not based on HTTP. For example, it can be used to intermediate between clients and a DNS server for DNS lookup, or between clients and an NTP server for clock synchronization. For more information, see Configuring TCP-UDP Proxy Servers. |